staging.inyokaproject.org

Der PC fährt nur nach Drücken der Eingebetaste hoch.

~# update-grub
Sourcing file `/etc/default/grub'
/usr/sbin/grub-mkconfig: 279: cannot create /boot/grub/grub.cfg.new: Directory nonexistent

Das Problem hatte ich mit 24.04.2 nicht. Ist das ein bekannter Bug?

~# cat /etc/default/grub
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""

GRUB_GFXMODE=1280x720
GRUB_GFXPAYLOAD_LINUX=keep


# If your computer has multiple operating systems installed, then you
# probably want to run os-prober. However, if your computer is a host
# for guest OSes installed via LVM or raw disk devices, running
# os-prober can cause damage to those guest OSes as it mounts
# filesystems to look for things.
#GRUB_DISABLE_OS_PROBER=false

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

https://askubuntu.com/questions/362720/sudo-update-grub-doesnt-work

Edit:

Die Lösung ist simpel:

mkdir /boot/grub
update-grub
reboot # Test ob PC hochfährt

$ ls -1 /boot/grub
grub.cfg
grubenv

Ich verwende eine eigene /boot-Partition (ext4), aber das sollte doch kein Problem sein.

Wäre zu einfach gewesen, irgendwann blieb es beim Grub-Menü wieder stehen.

Ein "Update-grub" hilft, aber die 2 Sekunden Wartezeit beim Grub-Menü dauern viel länger.

Was haste vorher gemacht?

Was ich gemacht habe ist davor beschrieben und davor neuen PC mit 24.04.3 installiert.

Letzter Stand:

/etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
GRUB_GFXMODE=1280x720
GRUB_GFXPAYLOAD_LINUX=keep

~$ sudo update-grub

Sourcing file `/etc/default/grub'
Generating grub configuration file ...
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Adding boot menu entry for UEFI Firmware Settings ...
done

Es könnte auch sein, dass der PC nach dem Anlegen des Ordners immer gestartet ist. Ich habe langsam bis 15 gezählt und bin dann gegangen, als ich zurückkam war der PC hoch gefahren.

Ich merke, ich habe bei der Partitionierung Mist gebaut, die /boot (jetzt xfs, eigentlich ext4) sollte /home sein

/dev/nvme0n1p1 vfat      1.2G    6.5M  1.2G    1% /boot/efi
/dev/nvme0n1p3 ext4      128G     22G  100G   19% /
/dev/nvme0n1p4 xfs       150G    3.0G  148G    2% /boot

Gerät              Anfang       Ende   Sektoren  Größe Typ
/dev/nvme0n1p1       2048    2203647    2201600     1G EFI-System
/dev/nvme0n1p2    2203648   10016767    7813120   3.7G Linux-Dateisystem
/dev/nvme0n1p3   10016768  263923711  253906944 121.1G Linux-Dateisystem
/dev/nvme0n1p4  263923712  556894207  292970496 139.7G Linux-Dateisystem
/dev/nvme0n1p5  556894208  565684223    8790016   4.2G Linux-Dateisystem
/dev/nvme0n1p6  565684224  829358079  263673856 125.7G Linux-Dateisystem
/dev/nvme0n1p7  829358080 1132093439  302735360 144.4G Linux-Dateisystem
/dev/nvme0n1p8 1132093440 3983656959 2851563520   1.3T Linux-Dateisystem
/dev/nvme0n1p9 3983656960 4000794623   17137664   8.2G Linux Swap

nvme0n1p2 sollte /boot sein, weiß nicht wie das geht 2x /boot anzugeben. Ich nehme an, das 2. Mal wird aktiv und das 1. Mal deaktiviert. Aber eigentlich sollte as egal sein, ein riesiges /boot zu haben.

glaskugel schrieb:

/etc/default/grub

GRUB_DEFAULT=0
GRUB_TIMEOUT_STYLE=hidden
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Ubuntu} ) 2>/dev/null || echo Ubuntu`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
GRUB_GFXMODE=1280x720
GRUB_GFXPAYLOAD_LINUX=keep

Das markierte schliesst sich gegenseitig aus. Wenn hidden dann werden die 30 Standardsek. genommen.

Stell von hidden auf menu um dann wirds auch mit der Zeiteinstellung klappen.

glaskugel schrieb:

Die Lösung ist simpel: …

Du hast jetzt aber nur ein Bruchteil dessen, was während der Installation unterhalb von /boot abgelegt wurde. Das System mag im Moment zwar starten, aber bei einer kleinen Änderung in der Hardware kann das dir wieder auf die Füße fallen.

glaskugel schrieb:

Ich merke, ich habe bei der Partitionierung Mist gebaut, die /boot (jetzt xfs, eigentlich ext4) sollte /home sein

Jau. Eine 1,2 G EFI ist auch Platzverschwendung. Wozu eigentlich eine separate Partition für /boot (nicht verwechseln mit /boot/efi), wenn du nicht verschlüsselt hast? Notwendig ist das so jedenfalls nicht.

… Aber eigentlich sollte as egal sein, ein riesiges /boot zu haben.

Ist notiert. Wenn du Probleme aufgrund mangelnden Speicherplatzes auf / bekommst, brauchst du dich nicht zu melden – sonst bekommst du dieses Thema verlinkt. 😉 Alle Daten landet derzeit auf der 128 GB Partition; du verschenkst also rund 149 G; Darauf kannst du lediglich alte Kernel sammeln bis zum Abwinken.

Ich würde noch mal installieren, aber diesmal richtig.
jm2c

PS:
Ich nehme an, dass du während der Installation /boot richtig angegeben hattest, aber im Nachgang etwas verändert hast, so dass /boot eben nur noch ein leeres Verzeichnis war. Das müsste anhand der /etc/fstab noch ersichtlich sein.

Eine 1,2 G EFI ist auch Platzverschwendung

Mag sein, das hat die Ubuntuinstallation automatisch erstellt.

Wozu eigentlich eine separate Partition für /boot (nicht verwechseln mit /boot/efi), wenn du nicht verschlüsselt

Soll da sein, falls ich das mal will.

Wenn du Probleme aufgrund mangelnden Speicherplatzes auf / bekommst

Sicher nicht, 50G würden auch reichen. Habe nur so viel genommen, weil ich manchmal viel in /tmp brauche und ich weiß auch nicht, was mir die audit-logs verschwenden

Ich nehme an, dass du während der Installation /boot richtig angegeben hattest, aber im Nachgang etwas verändert hast

Ich habe nichts verändert und ob ich bei der Partitionierung einen Fehler gemacht habe, keine Ahnung, will das aber nicht ausschließen. Ich hatte vorher eine genaue Partitionierungsliste erstellt, aber irren kann man sich immer. Ich habe vor dem Installationsstart auch nicht kontrolliert, war ja alles neu, konnte also nichts verloren gehen.

Ich würde noch mal installieren, aber diesmal richtig.

Ich hatte das sowieso vor. Ich war nur mal interessiert, was im neuen PC verbaut wurde und ob die Intel-Grafikkarte funktioniert. Es kommen noch 2 vorhandene 10T-HDDs rein. Meine "Daten" sind alle auf eigenen Partitionen, / und /home hat nur unwichtiges und ist überdimensioniert.

Alle Daten landet derzeit auf der 128 GB Partition

So gesehen stimmt das nicht. Zur Zeit gibt es 2+2+4 TB mit NVMe.

PS: der PC bootet jetzt schneller mit "menu".